Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-112

Text File | 1995-12-31 | 51KB | 1,256 lines

C.S.M.P. Digest             Thu, 21 Sep 95       Volume 3 : Issue 112

Today's Topics:

        Apple Events to open HTML file to specific anchor?
        How to watch a mem location in Macsbug?
        MacTcp and TimeManager
        Patching _Launch (68K)
        Thread Question
        When (and how) to use WRefcon



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroups
comp.sys.mac.programmer.help, csmp.tools and csmp.misc. It is designed for
people who read news semi-regularly and want an archive of the discussions.
If you don't know what a newsgroup is, you probably don't have access to
it. Ask your systems administrator(s) for details. If you don't have access
to news, you may still be able to post messages to the group by using a
mail server like anon.penet.fi (mail [e-mail] for more
information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Thomas Reed)
Subject: Apple Events to open HTML file to specific anchor?
Date: Thu, 31 Aug 1995 15:25:04 -0500
Organization: Washington University

I know how to open the HTML file, but I'm wondering if there's a way to
open it to a specific anchor.

I know how to do it using HTML Viewer, but the author said that there
isn't a standard.  So, it would appear that I will need to know a method
for each browser -- if there is one.  Yech.

Also, does anyone have a list of all the browsers available?

Thanks in advance!

-Thomas

=====================================================
Thomas Reed                     Washington University
[e-mail]               Medical School
[e-mail]            Saint Louis, MO
http://medinfo.wustl.edu/~reed
- ---------------------------------------------------
Clothes make the man.  Naked people have little or no
influence on society.  -- Mark Twain
=====================================================

Opinions posted are not the opinions of Wash. U.

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Thu, 07 Sep 1995 11:42:48 +0800
Organization: Underemployed, and loving it!

In article <[e-mail]>,
[e-mail] (Thomas Reed) wrote:

>I know how to open the HTML file, but I'm wondering if there's a way to
>open it to a specific anchor.
>
>I know how to do it using HTML Viewer, but the author said that there
>isn't a standard.  So, it would appear that I will need to know a method
>for each browser -- if there is one.  Yech.

Surely you can just do this with the Get URL suite, sending the browser a
"file" URL.  For example, if I command click on this URL...

<file:///SuperGrover/Desktop
Folder/Ideology/HumanInterfaceSubtleties.html#PointerObscuring>

... MacWeb loads the file off my local hard disk and scrolls to the
relevant section.

The GURL AppleEvent suite is documented in a file available from...

   ftp://ftp.acns.nwu.edu/pub/newswatcher/

Share and Enjoy.
--
Quinn "The Eskimo!"      "That's it, take me to your secret government
                          labs and cut me into wafer thin sections."

---------------------------

>From [e-mail] (Jay Zipursky)
Subject: How to watch a mem location in Macsbug?
Date: Tue, 05 Sep 1995 18:09:51 -0800
Organization: Creo Products Inc.

Hi folks,

I'm grappling with Macsbug once again.  I want my app to break when a
certain memory location is equal to 0.  Can I do this using Macsbug?  If
so, how?

Thanks for any help,
Jay

--
Jay Zipursky                  | [e-mail]
Software Engineer             | Voice [phone]
Creo Products Inc.            | Fax   [phone]
Burnaby, B.C., Canada         | <Insert Cool Quote Here>

+++++++++++++++++++++++++++

>From [e-mail] (David A. Lyons)
Date: Wed, 6 Sep 1995 04:04:48 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <JZipursky-0509951809510001@192.197.216.118> [e-mail] (Jay Zipursky) writes:
>Hi folks,
>
>I'm grappling with Macsbug once again.  I want my app to break when a
>certain memory location is equal to 0.  Can I do this using Macsbug?  If
>so, how?

Well...you can use a condition on any breakpoint or A-Trap break, so you
can  ATB (123456^.W = 0), which will break on *any* A-Trap when the
condition is true.

You can also StepSpy on your location, and you'll break *when the value
changes*, but there's currently no way to wait for it to change to a
particular value (other than manually repeating the SS command each time
you break, looking for the value you want).

I hope to get "SS <boolean expression>" into a future MacsBug; it would
step until the expression became true.
--
Dave Lyons
Mr Tangent


+++++++++++++++++++++++++++

>From [e-mail] (Chris Wysocki)
Date: Wed, 6 Sep 1995 07:13:19 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <[e-mail]>, David A. Lyons
<[e-mail]> wrote:

>You can also StepSpy on your location, and you'll break *when the value
>changes*, but there's currently no way to wait for it to change to a
>particular value (other than manually repeating the SS command each time
>you break, looking for the value you want).
>
>I hope to get "SS <boolean expression>" into a future MacsBug; it would
>step until the expression became true.

It would be really cool if MacsBug's Step Spy could be made to work
for PowerPC code; last time I tried it (which was a few MacsBug revs
back), it would only break at the first 68K instruction after the
chunk of PPC code that had stomped on the location being spied upon,
which isn't all that useful.  I can appreciate the difficulties that
could be involved with implementing Step Spy for PPC code, but I
figured I would mention it nonetheless....

Chris.

---------------------------

>From [e-mail] (Hee Kiang)
Subject: MacTcp and TimeManager
Date: 30 Aug 1995 08:14:42 GMT
Organization: National University of Singapore

In my application I need to continuosly send data to a remote client using
MacTcp. I wanted to make the sending of data  a periodic time manager task.
But I am worried that it might cause some complications because I don't know
whether MacTcp make any calls directly or indirectly to the memory manager.
And TimeManager Task cannot handle calls to Memory Manager.

Does anybody have any suggestion this ??

Hee Kiang

+++++++++++++++++++++++++++

>From Charles B. Cranston <[e-mail]>
Date: 30 Aug 1995 16:42:30 GMT
Organization: Network Infrastructures UMD CSC

In article <4216li$[e-mail]> Hee Kiang,
[e-mail] writes:

> In my application I need to continuosly send data to a remote client using
> MacTcp. I wanted to make the sending of data  a periodic time manager task.
> But I am worried that it might cause some complications because I don't know
> whether MacTcp make any calls directly or indirectly to the memory manager.
> And TimeManager Task cannot handle calls to Memory Manager.

This is a very good question.  As far as I know the current
MacTCP only makes storage allocation calls on the buffers
you pass it for the connection (the buffer is actually made
into a small memory heap using a feature of the Mac heap
manager).  So while there is no problem with the System Heap
or the Application Heap, I might worry about reinterrupting
MacTCP when it is in the middle of doing something with one
of these private heaps.

One possibility is to make only asynchronous MacTCP calls.
If MacTCP is busy when such a call is made, the request will
be queued and processed either when MacTCP gets done or at
the next "driver periodic work" call to MacTCP at which time
memory is guaranteed to be valid.

Another possibility is to make your own code a Device Driver
and do timed work in response to "driver periodic work" calls.
This would be equivalent to patching "SystemTask" or
"GetNextEvent" in that a badly spinning application can
cause the events to stop happening.  But remember, MacTCP
depends on these periodic work events too, so you're hosed
anyway.

So if your code is an application it's probably best to just
time your periodic work on incoming events, since in the normal
case you will get those pretty reliably.

You need to take a VERY close look at OpenTransport and its
MacTCP backwards support capabilities, since there seem to
be some things OT doesn't do quite the same in this area...

+-+-+
Charles B. (Ben) Cranston <[e-mail]>
http://www.wam.umd.edu/~zben

+++++++++++++++++++++++++++

>From [e-mail] (Eric Scouten)
Date: Wed, 30 Aug 1995 12:03:04 -0500
Organization: Huh? What's that?

In article <4216li$[e-mail]>, [e-mail] (Hee Kiang) wrote:

> In my application I need to continuosly send data to a remote client using
> MacTcp. I wanted to make the sending of data  a periodic time manager task.
> But I am worried that it might cause some complications because I don't know
> whether MacTcp make any calls directly or indirectly to the memory manager.
> And TimeManager Task cannot handle calls to Memory Manager.

This is fine. I've called MacTCP from inside Time Manager tasks and Sound
Manager callbacks w/o any problems.

IMPORTANT WARNING: You *MUST* make the calls to MacTCP asynchronously. If
you spin-wait for the MacTCP calls to complete inside an interrupt-service
routine, no other ISRs can fire (including MacTCP) so the machine *will*
lock up immediately. (It doesn't matter whether you have MacTCP wait by
making the calls synchronously or you call MacTCP asynchronously then
spin-wait until the completion flag is set. Both are unacceptable.)

As for memory allocation, MacTCP preallocates all the memory it needs
internally (thus the limitation that you can only have a total of 64
connections open across all applications at any time) or asks you to
preallocate the memory (i.e. stream buffers) before opening the channel.
You'll have to preallocate that buffer before starting the timer task.
Assuming you do your part right, MacTCP will be fine at interrupt level.

-es

__________________________________________________________________________
Eric Scouten                                       Constructor Constructor
[e-mail]                                     Metrowerks, Inc.

Don't wake me up 'til my haircut comes back in style.

+++++++++++++++++++++++++++

>From Richard Wesley <[e-mail]>
Date: 30 Aug 1995 21:18:30 GMT
Organization: Punch Deck Consulting

[e-mail] (Eric Scouten) wrote:
>In article <4216li$[e-mail]>, [e-mail] (Hee Kiang) wrote:
>
>> In my application I need to continuosly send data to a remote client using
>> MacTcp. I wanted to make the sending of data  a periodic time manager task.
>> But I am worried that it might cause some complications because I don't know
>> whether MacTcp make any calls directly or indirectly to the memory manager.
>> And TimeManager Task cannot handle calls to Memory Manager.
>
>This is fine. I've called MacTCP from inside Time Manager tasks and Sound
>Manager callbacks w/o any problems.
>
>IMPORTANT WARNING: You *MUST* make the calls to MacTCP asynchronously. If
>you spin-wait for the MacTCP calls to complete inside an interrupt-service
>routine, no other ISRs can fire (including MacTCP) so the machine *will*
>lock up immediately. (It doesn't matter whether you have MacTCP wait by
>making the calls synchronously or you call MacTCP asynchronously then
>spin-wait until the completion flag is set. Both are unacceptable.)
>
>As for memory allocation, MacTCP preallocates all the memory it needs
>internally (thus the limitation that you can only have a total of 64
>connections open across all applications at any time) or asks you to
>preallocate the memory (i.e. stream buffers) before opening the channel.
>You'll have to preallocate that buffer before starting the timer task.
>Assuming you do your part right, MacTCP will be fine at interrupt level.

In addition to this, I would heartily recommend that you use deferred tasks,
unless you are doing something that is guarenteed to take no time, or
you need precise control over the timing.  Your TMTask can wake up, trigger
the Deferred Task and then return.

- rmgw

http://www.punchdeck.com/hawkfish/PunchDeck.html

- --------------------------------------------------------------------------
Richard Wesley  [e-mail] | "'Hand it round first, and cut it
Punch Deck Consulting [e-mail] |  afterwards.'" - Lewis Carroll,
     Macintosh Software Development    |    "Through the Looking Glass"
- --------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Thu, 07 Sep 1995 17:58:30 +0800
Organization: Stairways Software

In article <4216li$[e-mail]>, [e-mail] (Hee Kiang) wrote:

>In my application I need to continuosly send data to a remote client using
>MacTcp. I wanted to make the sending of data  a periodic time manager task.
>But I am worried that it might cause some complications because I don't know
>whether MacTcp make any calls directly or indirectly to the memory manager.
>And TimeManager Task cannot handle calls to Memory Manager.

If you do async calls, then they can be called from interupt time, either
a completion task, a time manager taks, a deferred task or any other
interupt time.

I've just written come code that does exactly what you describe above
using MacTCP (over Open Transport) and it works fine for me.
   Peter.
--
"there is no significant correlation to violence on TV and agression in
daily life" - NHR Broadcasting Culture Research Institute in Tokyo.

---------------------------

>From [e-mail] (Michael J. Fromberger)
Subject: Patching _Launch (68K)
Date: 1 Sep 1995 21:53:58 GMT
Organization: Dartmouth College, Hanover, NH, USA

Hello there,

I am attempting to head-patch the _Launch toolbox trap under System
7.5.1, and I am encountering some difficulties, which I wonder if you
could help me resolve?

I have written my patch, which sets up a few parameters, gets the
address of the "unadulterated" _Launch routine, and jumps there.  This
aspect of it works just fine.

However, the Finder doesn't seem to want to use my patched version of
_Launch.  In fact, although my patch is used when the Finder is
invoked, the Finder itself seems to bypass my code, so my routine
never gets used.

Needless to say, this is somewhat troublesome -- the point of doing
this in the first place is to affect applications which are launched
from the Finder.  Does anyone know what might be happening?  Or,
alternately, can someone direct me to some alternate sources of
information?  I couldn't find anything particularly relevant in the
Tech Notes, although I may not have looked hard enough.

Thanks in advance!
-M

--
Michael J. Fromberger
Consultant, Postmaster Group, Academic Unix Group
Dartmouth College, Hanover, New Hampshire, USA
[e-mail] / [e-mail]

"I wish I was on yonder hill,
'Tis there I'd sit and cry my fill,
 Until every tear would turn a mill..."


+++++++++++++++++++++++++++

>From [e-mail] (Brian Bechtel)
Date: Sun, 03 Sep 1995 16:43:51 -0700
Organization: Apple Computer, Inc.

In article <427vdm$[e-mail]>, [e-mail]
(Michael J. Fromberger) wrote:

> Hello there,
>
> I am attempting to head-patch the _Launch toolbox trap under System
> 7.5.1, and I am encountering some difficulties, which I wonder if you
> could help me resolve?

You can't patch Launch until the Process Manager is up and running.  The
Process Manager replaces the Launch trap with its own, ignoring all
patches.
Patch something likely to be used by the first application starting up
(e.g. InitGraf) and patch Launch at that time.  Remove your patch to
InitGraf while you're at it, so you don't waste other people's time after
your initialization.

--
--Brian Bechtel    [e-mail]    Village Idiot, DTS

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Tue, 05 Sep 1995 18:59:57 -0800
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Brian Bechtel) wrote:

 > Patch something likely to be used by the first application starting up
 > (e.g. InitGraf) and patch Launch at that time.

Some extensions call InitGraf during startup, which means you also need:

   if (-1 != *LMGetCurApName ( ))
   {
      // INIT time is over
   }

I'm also skeptical whether patching at this time will work. If you patch
when an app has started up, this means the Process Manager is already
managing trap addresses, which means you can only patch one app at a time.
See below for a hint on what to do about this.

 > Remove your patch to InitGraf while you're at it, so you don't
 > waste other people's time after your initialization.

Even if you succeed in finding a way to patch Launch once for all apps,
this is still tricky because someone else may well have patched InitGraf
on top of you. I favor setting a flag after a patch has run the first
time. It doesn't cost much time to test a flag and get out, especially
since this is InitGraf, which is only called once per app (sort of, as
discussed below).

If you leave your InitGraf patch in, you'll be able to patch Launch in
each app's trap table. You'll have to maintain your own table of process
serial numbers so you can avoid patching the same app twice because the
disk initialization package may call InitGraf after the app does (strange
but true!), *and* you'll have to patch ExitToShell so you can tell when a
process is going away so you can take it out of the table.

Also, if you leave your patch to InitGraf in, you may well not need to
patch Launch at all, since apps all call InitGraf when they start up. If
you want to manage Launch itself, then you'll still have to patch Launch.

Does it sound like I've done this before? Don't answer that. :-)

--
 Pete Gontier // Software reenignE
 Macintosh Developer Technical Support // Apple Computer, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Scott Kevill)
Date: Thu, 07 Sep 1995 23:05:22 +0800
Organization: The University of Western Australia

In article <[e-mail]>,
[e-mail] (Brian Bechtel) wrote:

: In article <427vdm$[e-mail]>, [e-mail]
: (Michael J. Fromberger) wrote:
:
: > Hello there,
: >
: > I am attempting to head-patch the _Launch toolbox trap under System
: > 7.5.1, and I am encountering some difficulties, which I wonder if you
: > could help me resolve?
:
: You can't patch Launch until the Process Manager is up and running.  The
: Process Manager replaces the Launch trap with its own, ignoring all
: patches.
:
: Patch something likely to be used by the first application starting up
: (e.g. InitGraf) and patch Launch at that time.  Remove your patch to
: InitGraf while you're at it, so you don't waste other people's time after
: your initialization.
:
: --
: --Brian Bechtel    [e-mail]    Village Idiot, DTS

How do you safely remove your InitGraf patch without affecting any other
InitGraf patches that might have been installed?

The only way I could see is to set a flag once you are finished so you can
skip your tests from then on.

Scott Kevill
[e-mail]

---------------------------

>From [e-mail] (MarkWomack)
Subject: Thread Question
Date: 1 Sep 1995 20:01:30 -0400
Organization: America Online, Inc. (1-800-827-6364)

I am looking to implement a program using threads, and I have 2 questions:

1) according to the MacTech article I read, preemptive threads are not
allowed on PPC.  Is this still true?

2) Is is possible to pause a thread, save it's state information to a
file, quit the application, restart the application at a later date and
re-invoke the thread with the saved state info, picking up where it left
off??  Sounds Wierd, I know, but the operation I am thinking of doing
might take days to complete.

Thanks in advace for any info!
Mark

+++++++++++++++++++++++++++

>From Scott Thompson <[e-mail]>
Date: 5 Sep 1995 13:52:27 GMT
Organization: Macromedia

>> 1) according to the MacTech article I read, preemptive threads are
>> not allowed on PPC.  Is this still true?

According to the latest information I've seen in the recent releases of
the Developer CD, the thread manager for PPC still does NOT support
preemptive threads.  What's more, the documentation does not mention
preemptive threads for 68k machines although they seem to work (at least
on my machine).  I think their use is frowned upon by
"those-who-instill-the-blessings"

>> 2) Is is possible to pause a thread, save it's state information to a
>> file, quit the application, restart the application at a later date
>> and re-invoke the thread with the saved state info, picking up where
>> it left off??  Sounds Wierd, I know, but the operation I am thinking
>> of doing might take days to complete.


I would believe that your best bet is to find some way of saving your
application's progress information and then restoring that information
and creating a new thread to continue processing.  There are numerous
problems with saving the thread information itself (i.e. the current
register status of the CPU, the current location of the Stack pointer,
etc...) not the least of which is the fact that your executable code may
be loaded into a different section of memory when you restart the
application thereby making your PC invalid.



+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Wed, 06 Sep 1995 10:34:57 -0800
Organization: Apple Computer, Inc.

In article <42hkmr$[e-mail]>,
Scott Thompson <[e-mail]> wrote:

 > >> 1) according to the MacTech article I read, preemptive threads are
 > >> not allowed on PPC.  Is this still true?
 >
 > According to the latest information I've seen in the recent releases of
 > the Developer CD, the thread manager for PPC still does NOT support
 > preemptive threads.  What's more, the documentation does not mention
 > preemptive threads for 68k machines although they seem to work (at least
 > on my machine).  I think their use is frowned upon by
 > "those-who-instill-the-blessings"

I think the current official line is that the Thread Manager will never
support pre-emptive threads on PPC. For pre-emptive tasks on PPC, you'll
have to wait for Copland. Accordingly, pre-emptive thread support on 68K
has been withdrawn. If it still works, it's only for compatibility; you
shouldn't start a project today that relies on it.

I'm just the messenger.

--
 Pete Gontier // Software reenignE
 Macintosh Developer Technical Support // Apple Computer, Inc.

---------------------------

>From [e-mail] (Sam Huffman)
Subject: When (and how) to use WRefcon
Date: 29 Aug 1995 18:31:56 GMT
Organization: University of Michigan

I have a simple application that can have as many as 10 modeless dialog
boxes open at once (all contain the same type of information--it's like
having 10 word processing docs open in wordperfect).

Each of these dialog boxes has fields for information which is used in a
calculation. I currently have two arrays that I use to store the data and
dialog boxes, i.e.

DialogPtr gDialogList[MAXDIALOGS];
struct dialogGlobalList gDialogGlobals[MAXDIALOGS];

So my questions are

1) Is this an appropriate place to use SetWRefCon, and store the
information that would be in gDialogGlobals there?

2) If so, how exactly is this done? Is it as simple as putting the
following code in my CreateDialog procedure?

struct dialogGlobalList *gDialogGlobals;
.
. // The Dialog Initialization Code
.
gDialogGlobals = NewPtr(sizeof(struct dialogGlobalList));
SetWRefCon(theDialog, (long) gDialogGlobals);

and then I'm done? Or am I missing something?

Thanks for any help! This would clean up my code a lot... I would have
tried this except it means a lot of modifications, and if it doesn't work
It would mean a lot of back-peddling.

Sam Huffman
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (PandH Phot)
Date: 29 Aug 1995 16:47:18 -0400
Organization: America Online, Inc. (1-800-827-6364)

Maybe I'm missing something, but couldn't you do away with globals
entirely? How about something like this: create a user-defined structure
which includes all variables which related directly to the information in
a single dialog box; define a pointer type for that structure; use NewPtr
(per your code) to create an instance of that structure; use SetWRefCon to
store that pointer in the window's record.

This works pretty well for me: I don't have to decide which array element
belongs to a dialog. When I get a dialog event I just GetWRefCon and I
know right away which data to use (it's the only data I have a pointer
to). No globals: very cool.

Good luck!

Paul

+++++++++++++++++++++++++++

>From [e-mail] (Sean Crist)
Date: 30 Aug 1995 02:25:25 GMT
Organization: University of Pennsylvania

In article <[e-mail]>,
Sam Huffman <[e-mail]> wrote:

>1) Is this an appropriate place to use SetWRefCon, and store the
>information that would be in gDialogGlobals there?

Absolutely.  This is very good programming practice.

>2) If so, how exactly is this done? Is it as simple as putting the
>following code in my CreateDialog procedure?
>
>struct dialogGlobalList *gDialogGlobals;
>.
>. // The Dialog Initialization Code
>.
>gDialogGlobals = NewPtr(sizeof(struct dialogGlobalList));
>SetWRefCon(theDialog, (long) gDialogGlobals);
>
>and then I'm done? Or am I missing something?

I don't know C, but from what I can make out, that looks fine.  However, I
would recommend that you use a handle rather than a pointer.

Actually, once you start doing things this way, you can do away with the
globals for the dialog pointers as well.  I don't keep any global
WindowPtr's or DialogPtr's at all; I identify each window by the data in my
RefCon handle.  If I want a particular window, I just call my SearchWindow
function which steps through the window list and gives me back a WindowPtr
(=DialogPtr) to the window I want.  For all my mousedown, update,
etc. routines, I just do a case (switch) depending on what kind of window
its RefCon data identifies it as.  If you're writing a program which
supports an indefinite number of windows, this is a very practical way to
manage them.

Keeping global dialogPtr's can be compared to keeping a leash for each dog;
my way is like having only dog tags, no leashes.  If you have a copy of the
Apprentice CD, look at SeansWindowManager to see how I manage windows this
way (I'll make this code available thru my homepage if there's interest).

  \/ __ __    _\_     --Sean Crist  ([e-mail])
 ---  |  |    \ /     For a free copy of the Bill of Rights, finger
  _| ,| ,|   -----    this account.  It's also available through
  _| ,| ,|    [_]     my homepage:
   |  |  |    [_]     http://babel.ling.upenn.edu/~kurisuto/homepage.html

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 30 Aug 1995 04:18:10 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>,
[e-mail] (Sam Huffman) wrote:

<I have a simple application that can have as many as 10 modeless dialog
<boxes open at once (all contain the same type of information--it's like
<having 10 word processing docs open in wordperfect).
<
<
<So my questions are
<
<1) Is this an appropriate place to use SetWRefCon, and store the
<information that would be in gDialogGlobals there?
<
<2) If so, how exactly is this done? Is it as simple as putting the
<following code in my CreateDialog procedure?
<
<and then I'm done? Or am I missing something?
<
<Thanks for any help! This would clean up my code a lot... I would have
<tried this except it means a lot of modifications, and if it doesn't work
<It would mean a lot of back-peddling.
<
<Sam Huffman
<[e-mail]


That's pretty much it.  One additional thing is that it is often helpful
to set the windowkind as well, when the window is created.  Use custom
windowkinds for the different types of windows that your application might
have.  Check the windowkind before doing anything with the pointer or
handle that you've stored in the refcon.  This way you know for sure what
the refcon means before you start dereferencing it.

____________________________________________________________________
Brian  Stern  {:-{)}                          [e-mail]
Toolbox commando and Menu bard.             Will FlushCache for Cash

+++++++++++++++++++++++++++

>From [e-mail] (Sam Huffman)
Date: 30 Aug 1995 13:10:41 GMT
Organization: University of Michigan

In article <[e-mail]>,
[e-mail] (Brian Stern) wrote:

> In article <[e-mail]>,
> [e-mail] (Sam Huffman) wrote:
>
> <I have a simple application that can have as many as 10 modeless dialog
> <boxes open at once (all contain the same type of information--it's like
> <having 10 word processing docs open in wordperfect).
> <
> <
> <So my questions are
> <
> <1) Is this an appropriate place to use SetWRefCon, and store the
> <information that would be in gDialogGlobals there?
> <
> <2) If so, how exactly is this done? Is it as simple as putting the
> <following code in my CreateDialog procedure?
> <
> <and then I'm done? Or am I missing something?
> <
> <Thanks for any help! This would clean up my code a lot... I would have
> <tried this except it means a lot of modifications, and if it doesn't work
> <It would mean a lot of back-peddling.
> <
> <Sam Huffman
> <[e-mail]
>
>
> That's pretty much it.  One additional thing is that it is often helpful
> to set the windowkind as well, when the window is created.  Use custom
> windowkinds for the different types of windows that your application might
> have.  Check the windowkind before doing anything with the pointer or
> handle that you've stored in the refcon.  This way you know for sure what
> the refcon means before you start dereferencing it.

Thanks to everyone for their help! A couple follow-up questions...

Can I set the windowKind to an arbitrary value? I.e. do any other Toolbox
calls depend on this being set to a particular value or is it something
that's only there for the programmer's benefit?

Do I need to maintain my own window list (through, for example, a "next"
field in my wrefcon structure)? Or is there a system window list that I
can take advantage of?

Thanks!

Sam Huffman
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 30 Aug 1995 14:31:59 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>,
[e-mail] (Sam Huffman) wrote:

<In article <[e-mail]>,
<[e-mail] (Brian Stern) wrote:
<
<> In article <[e-mail]>,
<> [e-mail] (Sam Huffman) wrote:
<>
<> <I have a simple application that can have as many as 10 modeless dialog
<> <boxes open at once (all contain the same type of information--it's like
<> <having 10 word processing docs open in wordperfect).
<> <
<> <
<> <So my questions are
<> <
<> <1) Is this an appropriate place to use SetWRefCon, and store the
<> <information that would be in gDialogGlobals there?
<> <
<> <2) If so, how exactly is this done? Is it as simple as putting the
<> <following code in my CreateDialog procedure?
<> <
<> <and then I'm done? Or am I missing something?
<> <
<> <Thanks for any help! This would clean up my code a lot... I would have
<> <tried this except it means a lot of modifications, and if it doesn't work
<> <It would mean a lot of back-peddling.
<> <
<> <Sam Huffman
<> <[e-mail]
<>
<>
<> That's pretty much it.  One additional thing is that it is often helpful
<> to set the windowkind as well, when the window is created.  Use custom
<> windowkinds for the different types of windows that your application might
<> have.  Check the windowkind before doing anything with the pointer or
<> handle that you've stored in the refcon.  This way you know for sure what
<> the refcon means before you start dereferencing it.
<
<Thanks to everyone for their help! A couple follow-up questions...
<
<Can I set the windowKind to an arbitrary value? I.e. do any other Toolbox
<calls depend on this being set to a particular value or is it something
<that's only there for the programmer's benefit?

Use windowKinds greater than 8 for your custom document windows.  The
DialogManager uses a value less than that and expects all alerts and
dialogs to have that value.

<
<Do I need to maintain my own window list (through, for example, a "next"
<field in my wrefcon structure)? Or is there a system window list that I
<can take advantage of?

There is a nextWindow field in each windowRecord.  So the windows in your
app form a linked list.  You can cycle through all the windows in your app
by walking this list starting from FrontWindow().  You might need to keep
your own list if that isn't sufficient for your needs.

<
<Thanks!
<
<Sam Huffman
<[e-mail]

____________________________________________________________________
Brian  Stern  {:-{)}                          [e-mail]
Toolbox commando and Menu bard.             Will FlushCache for Cash

+++++++++++++++++++++++++++

>From [e-mail] (Carl Gustafson)
Date: 30 Aug 1995 15:36:25 GMT
Organization: Imaging and Computer Vision Center, Drexel University

In article <[e-mail]>,
[e-mail] (Sam Huffman) wrote:

> Can I set the windowKind to an arbitrary value? I.e. do any other Toolbox
> calls depend on this being set to a particular value or is it something
> that's only there for the programmer's benefit?
>

Use a positive value. In Days Past, system windows, like DA windows, used
a negative windowkind. (IFIRC)


> Do I need to maintain my own window list (through, for example, a "next"
> field in my wrefcon structure)? Or is there a system window list that I
> can take advantage of?
>

The nextWindow field in the WindowRecord maintains a link to the next
window down. It gets resorted each time window stacking changes. You can
easily run from FrontWindow () to the backmost in your application (NULL)
by chasing the nextWindow pointers.

--
Carl Gustafson
Imaging and Computer Vision Center
Drexel University, Philadelphia, Penna
- ----------------------------------------------------------
I don't speak for Drexel, and Drexel doesn't listen to me...

+++++++++++++++++++++++++++

>From [e-mail] (Christopher Larson)
Date: 31 Aug 1995 16:48:58 GMT
Organization: UCLA, Computer Science Department

In article <[e-mail]> [e-mail] (Sam Huffman) writes:
< [ ... ]
>Can I set the windowKind to an arbitrary value? I.e. do any other Toolbox
>calls depend on this being set to a particular value or is it something
>that's only there for the programmer's benefit?

Desk accessories and drivers have windowKind values which are negative, so
those are off limits. The Dialog Manager expects all dialog boxes to have
a windowKind of dialogKind (which is 2, I think). Stick with anything
above 8 (which is a constant the name of which escapes me at the moment)
and you should be fine.

>Do I need to maintain my own window list (through, for example, a "next"
>field in my wrefcon structure)? Or is there a system window list that I
>can take advantage of?

The system keeps track of all the windows in one particluar process, sorted
by Z-order from front to back, in a linked list. You can call FrontWindow()
to get the windowPtr of the frontmost window and then use the nextWindow
field of the WindowRecord to find the window immediately beneath that.
Continue until nextWindow is NULL.

--Chris
_______________________________________________________________________________
Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
- -------------------------------------+---------------------------------------
(Insert Disclaimer Here)               | Who's the man ridin' in the sun?
UCLA Bruins--1995 NCAA Men's Basketball| Who's the man with the itchy gun?
             National Champions (yea!) | Who's the man who kills for fun?
Internet: [e-mail]  | Psycho Dad, Psycho Dad, PSYCHO DAD!

+++++++++++++++++++++++++++

>From [e-mail] (Matthias Neeracher)
Date: 03 Sep 1995 13:11:11 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]>, [e-mail] (Brian Stern) writes:
> In article <[e-mail]>,
> [e-mail] (Sam Huffman) wrote:
> <> <I have a simple application that can have as many as 10 modeless dialog
> <> <boxes open at once (all contain the same type of information--it's like
> <> <having 10 word processing docs open in wordperfect).

> <> That's pretty much it.  One additional thing is that it is often helpful
> <> to set the windowkind as well, when the window is created.  Use custom
> <> windowkinds for the different types of windows that your application might
> <> have.  Check the windowkind before doing anything with the pointer or
> <> handle that you've stored in the refcon.  This way you know for sure what
> <> the refcon means before you start dereferencing it.

> <Can I set the windowKind to an arbitrary value? I.e. do any other Toolbox
> <calls depend on this being set to a particular value or is it something
> <that's only there for the programmer's benefit?

> Use windowKinds greater than 8 for your custom document windows.  The
> DialogManager uses a value less than that and expects all alerts and
> dialogs to have that value.

An additional caveat: Sam is using modeless dialogs. At least a few years
ago, it was necessary for the windowKind of windows to be 2 for IsDialogEvent
and/or DialogSelect to succeed. This was especially interesting for windows
owned by desk accessories (which had to have the drvrRefNum as the window
kind). Therefore, a tech note demonstrated how to temporarily set the
windowKind to 2 and then reset it afterwards. Unfortunately, I failed to
find the technote (it's hard to find documentation about DA's nowadays).

> <Do I need to maintain my own window list (through, for example, a "next"
> <field in my wrefcon structure)? Or is there a system window list that I
> <can take advantage of?

> There is a nextWindow field in each windowRecord.  So the windows in your
> app form a linked list.  You can cycle through all the windows in your app
> by walking this list starting from FrontWindow().  You might need to keep
> your own list if that isn't sufficient for your needs.

Another minor comment here: nextWindow links a list of *all* windows - visible
or not. The head of the list is returned by LMGetWindowList(), while
FrontWindow() returns the frontmost *visible* window (unless that would be
LMGetGhostWindow(), but I'm only telling that to show off :-). FrontWindow()
is almost always what you want, but keep the distinction in mind.

Matthias

- ---
Matthias Neeracher <[e-mail]> http://err.ethz.ch/members/neeri.html
   "I'm set free to find a new illusion" -- Velvet Underground

+++++++++++++++++++++++++++

>From [e-mail] (Mark H. Linton)
Date: 4 Sep 95 10:08:45 EST
Organization: HRB Systems, Inc.

In article <[e-mail]>, [e-mail] (Matthias Neeracher) writes:
> In article <[e-mail]>, [e-mail] (Brian Stern) writes:
>> In article <[e-mail]>,
>> [e-mail] (Sam Huffman) wrote:
>> <> <I have a simple application that can have as many as 10 modeless dialog
>> <> <boxes open at once (all contain the same type of information--it's like
>> <> <having 10 word processing docs open in wordperfect).
>
>> There is a nextWindow field in each windowRecord.  So the windows in your
>> app form a linked list.  You can cycle through all the windows in your app
>> by walking this list starting from FrontWindow().  You might need to keep
>> your own list if that isn't sufficient for your needs.

I presume you are not hoping to make your application work when Copland comes
out. The new system will gradually phase out WindowPtr's in favor of
WindowRef's (an opaque data type) in order to allow Apple to redefine thw
window structure. Try compiling your application with STRICT_WINDOWS defined to
one. When you get all the compiler errors fixed, you will see that knowledge of
the WindowRecord structure is no longer helpful.

To make a long story short... Yes, you have to maintain your own window list.

To be really helpful. Try keeping a list of your applications documents, each
item in the list can have one or more windows associated with it. When you get
a window event, walk your document list and look at each of your document
windows, if you don't find a match, it must be one of your dialogs. You also no
longer care about the WindowRecord structure and you are insulated from changes
Apple may make in the future.

--
Hope this helps.

Mark H. Linton
____________________________________________________________________
mark \'märk\ n [ME, fr. OE mearc boundary, march, sign; akin to OHG
marha boundary, L margo] 1 a : a conspicuous object serving as a guide
for travelers 2 : A standard or criterion of quality 3 : An object or
point that serves as a guide --idiom. mark time. 1 : To make little or
no progress

+++++++++++++++++++++++++++

>From [e-mail] (Sean Crist)
Date: 5 Sep 1995 18:47:12 GMT
Organization: University of Pennsylvania

In article <1995Sep4.100845.23655@hrbicf>,
Mark H. Linton <[e-mail]> wrote:
>In article <[e-mail]>, [e-mail] (Matthias Neeracher) writes:

>>> There is a nextWindow field in each windowRecord.  So the windows in your
>>> app form a linked list.  You can cycle through all the windows in your app
>>> by walking this list starting from FrontWindow().  You might need to keep
>>> your own list if that isn't sufficient for your needs.
>
>I presume you are not hoping to make your application work when Copland comes
>out. The new system will gradually phase out WindowPtr's in favor of
>WindowRef's (an opaque data type) in order to allow Apple to redefine thw
>window structure. Try compiling your application with STRICT_WINDOWS
>defined to one. When you get all the compiler errors fixed, you will see
>that knowledge of the WindowRecord structure is no longer helpful.
>
>To make a long story short... Yes, you have to maintain your own window list.

You've got to be kidding!  I certainly hope there's going to be _some_ way
to find the next window (visible or not), and to find the frontmost window
(visible or not) or all my applications are going to break badly; I've
built everything from the ground up on the assumption that I can do this.

Is there going to be some kind of function like this?

   function GetNextWindow(whichWindow: windowPtr) : windowPtr;

It's fine with me if I can get the next element of the linked list this
way, rather than by getting the nextWindow out of the structure myself, but
if there's no way for me to step through the window list, I'm seriously
screwed.

  \/ __ __    _\_     --Sean Crist  ([e-mail])
 ---  |  |    \ /     For a free copy of the Bill of Rights, finger
  _| ,| ,|   -----    this account.  It's also available through
  _| ,| ,|    [_]     my homepage:
   |  |  |    [_]     http://babel.ling.upenn.edu/~kurisuto/homepage.html


+++++++++++++++++++++++++++

>From [e-mail] (Mark H. Linton)
Date: 6 Sep 95 10:06:18 EST
Organization: HRB Systems, Inc.

In article <42i5vg$[e-mail]>,
   [e-mail] (Sean Crist) writes:
> In article <1995Sep4.100845.23655@hrbicf>,
> Mark H. Linton <[e-mail]> wrote:
>>
>>I presume you are not hoping to make your application work when Copland comes
>>out. The new system will gradually phase out WindowPtr's in favor of
>>WindowRef's (an opaque data type) in order to allow Apple to redefine thw
>>window structure. Try compiling your application with STRICT_WINDOWS
>>defined to one. When you get all the compiler errors fixed, you will see
>>that knowledge of the WindowRecord structure is no longer helpful.
>>
>>To make a long story short... Yes, you have to maintain your own window list.
>
> You've got to be kidding!  I certainly hope there's going to be _some_ way
> to find the next window (visible or not), and to find the frontmost window
> (visible or not) or all my applications are going to break badly; I've
> built everything from the ground up on the assumption that I can do this.
>
> Is there going to be some kind of function like this?

Hi Sean... don't freak out on me here... YES, THERE ARE _NOW_ ACCESSOR
FUNCTIONS FOR ALL OF THE COMPONENTS! I suggest you start using them. Look in
the header file <Windows.h>. There is quite a diatribe in the comments about
when/how to make your application work under Copland. There is also an Acrobat
"paper" on Copland compatibility available on the Apple web sites.

If that sounds like too much effort and you want to learn it a little at a
time... do just what I said... #define STRICT_WINDOWS 1 and go through and
clean up the compiler errors. As you fix each one, you will learn what the new
accessor function is (they're all macros now).

>
>    function GetNextWindow(whichWindow: windowPtr) : windowPtr;
>
> It's fine with me if I can get the next element of the linked list this
> way, rather than by getting the nextWindow out of the structure myself, but
> if there's no way for me to step through the window list, I'm seriously
> screwed.

You're not "seriously screwed" and this is EXACTLY what is being done.

Spread the word... this is a GoodThing!(tm)

--
Hope this helps.

Mark H. Linton
____________________________________________________________________
mark \'märk\ n [ME, fr. OE mearc boundary, march, sign; akin to OHG
marha boundary, L margo] 1 a : a conspicuous object serving as a guide
for travelers 2 : A standard or criterion of quality 3 : An object or
point that serves as a guide --idiom. mark time. 1 : To make little or
no progress

+++++++++++++++++++++++++++

>From [e-mail] (Adam Winer)
Date: Wed, 06 Sep 1995 21:46:54 -0800
Organization: Oracle Corporation

In article <42i5vg$[e-mail]>, [e-mail]
(Sean Crist) wrote:

> In article <1995Sep4.100845.23655@hrbicf>,
> Mark H. Linton <[e-mail]> wrote:
> >In article <[e-mail]>, [e-mail]
(Matthias Neeracher) writes:
>
> >>> There is a nextWindow field in each windowRecord.  So the windows in your
> >>> app form a linked list.  You can cycle through all the windows in your app
> >>> by walking this list starting from FrontWindow().  You might need to keep
> >>> your own list if that isn't sufficient for your needs.
> >
> >I presume you are not hoping to make your application work when Copland comes
> >out. The new system will gradually phase out WindowPtr's in favor of
> >WindowRef's (an opaque data type) in order to allow Apple to redefine thw
> >window structure. Try compiling your application with STRICT_WINDOWS
> >defined to one. When you get all the compiler errors fixed, you will see
> >that knowledge of the WindowRecord structure is no longer helpful.
> >
> >To make a long story short... Yes, you have to maintain your own window list.
>
> You've got to be kidding!  I certainly hope there's going to be _some_ way
> to find the next window (visible or not), and to find the frontmost window
> (visible or not) or all my applications are going to break badly; I've
> built everything from the ground up on the assumption that I can do this.
>
> Is there going to be some kind of function like this?
>
>    function GetNextWindow(whichWindow: windowPtr) : windowPtr;
>
> It's fine with me if I can get the next element of the linked list this
> way, rather than by getting the nextWindow out of the structure myself, but
> if there's no way for me to step through the window list, I'm seriously
> screwed.

Actually, there currently is such a function in Windows.h (well,
a macro).  However, unlike the other accessor functions, it isn't
going to be supported in Copland.  The following quote from
Windows.h should explain this:

"These accessors will be available as true API entrypoints
in Copland, but are not guaranteed to match exactly.  Specifically,
GetNextWindow will not be supported and a whole new model for
iterating the window list will be presented.  Using GetNextWindow
for now is ok, however, as it will let you leverage the STRICT flags."

I would assume their rationale for not supporting GetNextWindow
has something to do with Copland's built-in support for
floating windows.  Anyway, I strenuously doubt that an application
built using GetNextWindow() would break under Copland;  too many
applications use it.  Of course, if you want to make a Copland-savvy
app, you'll have to get rid of any such calls, as well as any explicit
references to the WindowRecord structure.

-- Adam Winer
[e-mail]

---------------------------

End of C.S.M.P. Digest
**********************